Make transition() tolerances dynamic and fix its argument list (VAMS-2023, Mantis 7810) - #30

Part of the VAMS-2023 alignment effort tracked in #19.

Summary

VAMS-2023 Table 4-20 (Mantis 7810) moves the tolerance arguments of the analog event functions and of transition() out of the constant expression arguments column and into the dynamic expression arguments column. In VAMS 2.4 the same table lists transition's time_tol as a constant argument; in VAMS-2023 all five of its arguments are dynamic:

transition ( expr [ , td [ , rise_time [ , fall_time [ , time_tol ] ] ] ] )

OpenVAF got two separate things wrong here.

1. The signature list was truncated and mis-numbered. It stopped at four arguments and the arities were off by one from the third signature onwards (TRANSITION_DELAY_RISET took two arguments, not three). Two consequences on mob today:

y = transition(level, 0.0, tr, tf, tol);
// error: invalid argument count: expected at most 1 arguments but found 5

y = transition(level, 0.0, 1e-9, dyn_fall);
// error: constant expressions must not contain variable references
//   --> the 4-argument form matched the signature named `..._TOL`, so the
//       *fall time* was const-checked

2. time_tol was const-checked. With the arities corrected it still would have been, so transition is removed from the const-expression list in body validation. The tolerances Table 4-20 keeps constant — absdelay's maxdelay, ddt's and idt/idtmod's abstol — are deliberately left alone.

Lowering already read args[2]/args[3] as the rise and fall time, so it needed no change. td and time_tol do not affect the continuous (first-order lag) realization and are now documented as ignored rather than silently dropped.

Drive-by fix

The "too many arguments" diagnostic reported min_args instead of max_args, so every over-long call to an operator with optional arguments said "expected at most 1 arguments". It now reports the real maximum.

Deliberately not in scope

cross, above, timer and absdelta. Their tolerance arguments are already unrestricted, because OpenVAF does not resolve the event expression of @(...) at all yet — there is nothing to relax. Giving those four real signatures is a separate change with its own regression surface.

Test plan

• openvaf/test_data/ui/transition_tolerance.va — all five argument counts, plus a run-time rise time, fall time and time tolerance; compiles with an empty diagnostics log. The four- and five-argument cases both failed before this change.
• openvaf/test_data/ui/transition_tolerance_err.{va,log} — six arguments still rejected (now with the correct maximum in the message), and ddt/absdelay tolerances still required to be constant expressions.
• integration_tests/VAMS2023_TRANSITION_TOL/ + openvaf/test_data/osdi/vams2023_transition_tol.snap — end-to-end compile / link / load of a model whose transition rise time, fall time and tolerance are all computed at run time. --dump-unopt-mir shows the lag's time constant selected from the dynamic rise/fall values (phi [speed], [2*speed]) rather than from constants.

Verified locally with LLVM 18:

cargo test -p hir -p hir_ty -p hir_def -p hir_lower -p basedb -p syntax -p parser
RUN_DEV_TESTS=1 cargo test   # 38/37/42/34 integration models, all green
cargo test -p openvaf --features llvm18 --test integration   # OSDI descriptor snapshots
cargo fmt --all -- --check

🤖 Generated with Claude Code